In today's software development field, software components that are used in connection with an application are usually written by others, and are used and re-used, possibly with changes. This trend is increasing.
A package is conventionally used to organize a set of related components intended for use by a particular application. The package may contain, by way of example, content needed to reference an external library; source code, binaries, executables, classes, and interfaces; identifying information and a manifest that identifies requirements if the package; scripts, other packages, and related items that run when the package is installed, de-installed, and/or used by a software application. A developer of a file or package typically will publish the package with that file to a repository so that the package can be shared and re-used, such as by other developers.
The available tools for software development makes it easy to use packages and software components, but these tools do not make it easy to understand where the package or the files in the package originated. Compounding the lack of visibility and understanding is the fact that packages and files in packages tend to depend on other components and/or packages and files which may themselves be used or re-used, possibly with changes.
A software repository is a known technique to provide developers with a convenient collection of re-used and re-usable packages and software components, where the package and/or component in the software repository may be a copy or specialized version and/or may incorporate other components and/or packages such as by dependency. A conventional repository manager can be used as a central point of storage and exchange for packages and software component usage. Package management systems are available which can provide tools to automate distribution of packages, can maintain information about dependencies and version information, and can work with software repositories. For a single ecosystem which is a collection of software repositories and/or support systems all of which store interrelated files, there can be thousands of distinct software packages with their attendant files.
Nevertheless, the problem with visibility and understanding of packages and the software components remains. There may be numerous files in a repository which are essentially the same component but which might have minor variations in content and/or name; any of these components might have originated elsewhere in the ecosystem. Using a repository manager or a package manager to identify the software repository where an application, package or component is stored or managed, does not necessarily correctly identify where that package or component actually originated and does not necessarily identify the name of the original file or the package where the file originated.
In particular, with all of the sharing of files via packages, it remains problematic to correctly locate the original name and version of a file which appears in different packages, in combination with the original package which originated that component.